Claude finished @philippecamacho's task in 1m 36s —— View job

Code Review: Make constants in batch submission logic configurable

• Read existing review comments
• Review changed files
• Provide review feedback

Overall this is a clean, well-scoped PR. The functional options pattern is followed consistently, defaults are preserved, and the plumbing from CLI → service → driver → submitter is correct. A few observations:

Validation of zero/negative values

The new config fields (VerifyReceiptMaxBlocks, VerifyReceiptSafetyTimeout, VerifyReceiptRetryDelay) aren't validated in CLIConfig.Check(). Setting VerifyReceiptMaxBlocks to 0 would make the block-count check trigger re-submission on every first verification attempt, and a zero VerifyReceiptRetryDelay would cause a tight spin loop in the verify worker. I left an inline comment with a concrete suggestion for adding validation.

Duplicated defaults (echoing Gemini's feedback)

I agree with the existing review thread — the magic values 5, 5 * time.Minute, and 100 * time.Millisecond appear both in cli.go flag definitions and as VERIFY_RECEIPT_* constants in espresso.go. Exporting the constants and referencing them in the CLI flags would eliminate drift risk. Not blocking, but worth addressing.

evaluateVerification method receiver change — good call

Converting evaluateVerification from a free function to a method on *espressoTransactionSubmitter is the right move. It keeps the configurable values close to where they're used without parameter bloat.

No test coverage for the new configurability

There are no tests for evaluateVerification or the new With* options. Since evaluateVerification is a pure-logic decision function (no I/O), it would be straightforward to add table-driven tests exercising the different timeout paths with custom config values. Not a blocker for this PR, but would add confidence.

Minor: constant naming convention

The VERIFY_RECEIPT_* constants use SCREAMING_SNAKE_CASE, which is unusual for Go (idiomatic Go uses MixedCaps). Since these are now only used as internal defaults inside NewEspressoTransactionSubmitter, this is cosmetic and not worth a change in this PR.

Looks good overall — the main actionable item is the input validation.